1. Field of the Invention
This invention relates to systems for improving communication among people who are collaborating in the performance of a task.
2. Description of Related Art
Computers coupled to networks have made collaborative work easier than ever before. At the most fundamental level, file sharing and email have eliminated the requirement that collaborators be in physical proximity to each other. The change tracking arrangements that are provided by most document processing systems further support collaborative work, as do computer-implemented scheduling and tracking systems. Integrated systems for collaborative work provide features such as file sharing, email, change tracking, scheduling, and tracking in a single package. A problem with these tools and integrated systems for collaborative work is that they are very general. It is up to the user to adapt them to his or her needs. To be sure, a skilled user of a tool such as a spreadsheet can adapt the tool to almost any purpose, but to do this, extensive programming is required. Such programming requires a specialist, and the result of the programming is often opaque to those who are not masters of the tool and of what is being represented. Indeed, a general problem with tools that require extensive programming to adapt them to a user's needs is that the programming is usually done by a specialist who understand the tools or the system, but not the nature of the collaboration, and as is usual in such situations, communication between the programming specialist and the users is usually difficult and sometimes impossible.
Another approach to collaborative work has been systems that are specialized for collaborative work in a particular special area, such as bookkeeping. For example, the Quickbooks small business accounting software provides a model of a small business as seen from the point of view of an accountant that the user of Quickbooks can customize for his or her own purposes. While the model of the small business that Quickbooks provides is very useful for accounting, it has no relevance whatever to other aspects of the business.
Another approach is described in U.S. patent application Ser. No. 10/765,424 ('424 application). FIG. 34 shows a diagram of a model 4101 as described in the '424 application. A number of collaborators 4005 (1 . . . n) are organized into one or more collaborator groups 4003 (1 . . . m). A collaborator 4005 may belong to more than one group 4003. The context in which the collaborators 4005 work is represented by a domain hierarchies 4009 (1 . . . k), goal-project hierarchies 4011 (1 . . . m), and initiative hierarchies 4109 (1 . . . o).
Each goal-project hierarchy 4011 has at its head a project or a goal. A goal may have other goals and projects 4015 as its children. A project 4015 may have other projects as its children, but may not have a goal as a child. Any goal, project, domain, or initiative may have one or more items of information 4017 associated with it, as indicated by arrows 4105. The information may include documents, messages, discussions, reminders, Web links, and alerts. The ability to relate information 4017 directly to any kind of hierarchy entity is particularly useful when the information is global to the entire domain or initiative.
An initiative 4109 is not a member of any domain hierarchy 4010 or goal-project hierarchy 4011, but is rather the root of an initiative hierarchy 4111 which may include sub-initiatives and a single level of goals and/or projects from any of the goal-project hierarchies. A goal or project may belong to any number of initiatives. Information may be related to an initiative in the same way that it may be related to any hierarchy entity.
Access to domains, goals, and projects is by collaborator groups 4003. A given collaborator group 4003(i) may have access to any combination of domains, goals, projects, and initiatives in model 4101. The kinds of access which a collaborator belonging to a particular group has to a particular domain, goal, project, or initiative depend on the group's group type and the permissions which the group has for the particular domain, goal, project, or initiative.
Collaborators with the proper permissions may modify not only the information 4017 associated with a goal, project, domain, or initiative, but may also modify the form of the respective hierarchy.
A limitation of the model 4101 is that it provides only one view of the hierarchies' structure. This limits the usefulness of the model to more complex processes or organizations, where multiple views of the hierarchies would be helpful.
Background Concerning Parameterized Information Requests
The system of the parent application, while providing access to a number of information sources in useful ways, did not support information sources that respond to parameterized information requests. For example, it did not provide access to relational database management systems (RDBMS). The complexity of supporting parameterized information requests is illustrated in FIG. 35 for an example RDBMS system:                3500 shows the request parameter for a parameterized information request for this information source. The request parameter for this information source must be expressed in a dialect of the SQL query language.        3550 shows the data text of the information response, after special programming has converted it from the on-the-wire format for this particular information source.        
The example in FIG. 35 is for an RDBMS information source that provides information about security incidents. The request parameter at 3500 requests a list of recent security incidents and information about them. The response is a list of incidents and information as specified in the request parameter
Neither of the examples of FIG. 35 is understandable to general users
Parameterized information requests are an important feature of a system for information sharing and collaborative work:                Parameterized information requests allow a client of an information source to request specifically desired information.        Many information sources require support for parameterized information requests: they provide information only as a response to such requests in proper form.        
The difficulty with supporting parameterized information requests is that they are complex. They involve special programming at multiple levels, special languages for specifying what is requested, and special expertise.
For a system supporting real-time collaborative work, it is also important that appropriate users of the system can add new information sources and new parameterized information requests to the system quickly and with minimal difficulty.
There are many information sources that provide information in response to parameterized information requests. For example, an information source with real-time information about hospitals may be able to provide many kinds of information, such as the number of emergency-patent beds currently available in hospitals near a certain location. An information source about the weather may be able to provide many kinds of current information about weather conditions and weather forecasts for different locales on different days.
However, these systems provide the information only in response to parameterized information requests, in the form for the particular information source, that specify what information is requested.
The technical aspects of supporting parameterized information requests are a barrier to and a limitation on their use. There are difficulties and burdens associated with parameterized information request at several levels.
One burden is the need to have an appropriate user interface for requesting and presenting particular information from particular information sources as needed by the user. The user interface must provide support for parameterized information requests in a fashion that is not difficult for a general user.
Another burden is that query request parameters often must be expressed in a special query language. The example of 3500 uses a dialect of the SQL language.
However, many languages for query request parameters exist: while SQL is used for many RDBMS information sources, SQL is implemented in a number of dialects by different vendors. Another relevant language standard is SOAP, which involves the complex language XML. The ISO 8583 standard describes yet another such language for financial information, and the OCSP standard describes yet another language for computer security status. Many information sources involve yet other languages, and a language may even be unique to the particular information source.
General users of collaborative systems will not have expertise in these languages. Even for users who have some expertise in one particular language, the languages can be complex and awkward to use, and interfere with the tasks of real-time collaboration and information sharing.
A further barrier is that accessing multiple information sources generally requires expertise in multiple different programming systems, as different information sources are programmed differently. A further barrier is that different kinds of information sources must be accessed by different programming protocols and interfaces.
For example, Relational data base systems require programming according to JDBC Java classes, or another programming interface. Many information sources implemented as web services require programming according to SOAP method calls or other programming standards. Information sources implemented according to IBM's ESB Enterprise Service Bus require yet different programming. Yet other information sources require specialized programming unique to the particular source. There is also considerable variation in the programming for authentication, encryption, network protocols, and other aspects of the necessary programming, even for systems of the same kind.
It is thus an object of the present invention to overcome these limitations and to provide a system for collaborative work that permits collaborators to make parameterized information requests.